C3 — AI 营销内容生成 SaaS 场景指引

一、场景概述

本场景聚焦于验证 ZY AI Native Engine 在 B2B SaaS 订阅制业务模式下的全链路自动化运营能力。场景设定为一家由 1 人独立开发者创建的「输入品牌调性→自动生成博客/邮件/推文」的月费订阅工具，定价 $19/$49 两档，目标用户为中小企业的营销团队。

该场景的核心价值在于测试平台在毛利薄、预算敏感业务环境下的三大关键能力：双线账本体系下的预算三级控制机制（预警/降级/熔断/恢复）、A/B 测试驱动的持续迭代优化、以及客服邮件的自动化闭环处理。由于 SaaS 业务的边际成本特性，AI 运行预算的精确控制与熔断恢复机制成为本场景的核心关注点。

预算三级控制机制是本场景的核心测试点。系统通过 budget_states 表实时追踪 AI 运行预算的使用情况，当已用额度达到预警线（默认 80%）时触发预警通知，达到 100% 时自动熔断并暂停项目循环，人工补充预算后可通过产品 UI 恢复运行。整个流程需要确保：队列不丢失、状态可恢复、断点续跑、通知可达。

A/B 迭代能力体现在营销内容的持续优化上。系统通过 marketing_campaigns 和 marketing_contents 表管理多版本文案，通过事件注入模拟 A/B 测试结果，验证胜出方案能否自动进入模板库并留版本链，驱动后续轮次的 review 重排。

客服邮件闭环测试系统对用户咨询、退款请求、Bug 报告的自动化响应能力。通过 events 表注入客户支持邮件事件，验证 EventAgent 能否正确分类（usage/refund/bug）、派单给客服 Agent、起草回复并转入 connector_audit_logs 的 pending_review 队列等待人工审批，同时确保 GDPR 退订链接、无 spam 触发词等合规要求。

从 D1 到 D4 的实际测试历程表明，该场景经历了从冷启动断链（ISSUE-W4-01）到自挂链路打通（D2）、从预算口径失真（D3 判据校准）到三级控制全链演练（D4 预算钻取）的完整验证过程。D4 的成功实施证明了「预警→熔断→暂停→充值→恢复」的完整闭环在产品内可真实达成，为后续场景的预算控制测试提供了可复用的方法论。

二、场景目标与主战场能力

2.1 核心业务目标

本场景旨在验证平台能否支撑一家 AI 营销 SaaS 公司从 0 到 1 再到规模化的完整生命周期：

• T1 生存期（1-3 周）：完成产品上线、获得首个付费订阅、建立基础客服能力、经历至少一次完整的预算熔断恢复循环
• T2 扩张期（4-10 周）：实现 MRR $300、A/B 测试常态化、团队扩编至 1 人 + 11 AI、建立数据驱动的迭代机制
• T3 规模化期（11-30 周）：实现动态预算调度、月 churn 率 ≤5%、AI 成本占 MRR <6%、具备异常自愈能力

2.2 主战场能力验证

能力一：预算三级控制的精确性与可靠性

系统必须能够在预算消耗的 80% 节点准确触发预警，在 100% 节点自动熔断并暂停项目，且恢复后能够从断点续跑。D4 的实测数据显示：从 ¥4.70 下压预算到 ¥4.96 后，45 秒内 warned 标志从 false 翻转为 true，40 分钟 / 64 轮后真实越线触发熔断，ai_meltdown 置位、status 转为 paused、通知 id=60 以 urgent 优先级送达。恢复流程通过 UI「设置预算」补充到 ¥40 + 点击「恢复」按钮完成，round_no 从 592 连续到 593，无任何跳号或重跑。

能力二：FIX-003 为本卡成立前提

FIX-003（预算联动断裂修复）直接决定了本场景的可行性。在修复前，熔断只能通过人工查询 /autoops/billing 接口判断，「预警→暂停→恢复」链路无法自动化。修复后，budget.go:358 PreRoundCheck 在每轮开始前检查三道闸门：① 终止标志、② AI 预算线、③ 总预算线，独立持久化 ai_meltdown/total_meltdown 标志，并通过 WebSocket 广播状态变更。

2026-10-07 同步（V3-06 预算读面实时化）：GET /budget/state 读面此前直回持久旗标，预算调小后会出现「读面未熔断、start/resume 闸已拒绝」的口径漂移（V3 战役 T2b/T4 两轮复确认）。现读面在刷新消耗真值后按与闸门完全一致的判据实时重算两枚熔断旗标（只改返回视图、不落盘，持久旗标的置位与通知仍归 PreRoundCheck；消耗查询失败且配置了总预算时 fail-close 视为已超）。本卡预算演练的读数判据不变，预警/熔断标签在轮前即会如实反映。

但实测也暴露了 FIX-003 的局限性：single_round_max_budget 的调整被 ISSUE-W4-31 阻挡（UI 保存恒返回 500 错误，根因是 jsonl_poll_interval_sec 请求键与 GORM 物理列 json_l_poll_interval_sec 不匹配），导致单轮上限 ¥2 无法生效，只能停留在 ¥100。这意味着「单轮成本 ≤¥2」的硬断言虽然实测绿（46 轮 max 仅 ¥0.00491），但闸门本身未被验证。

能力三：A/B 迭代与客服闭环的协同

系统需要证明能够通过 A/B 测试持续优化营销内容，同时自动化处理客服邮件。A/B 测试的结果通过事件注入（如 marketing.ab_result）进入系统，驱动 review 轮重排优先级；客服邮件通过 customer.support 事件注入，触发 EventAgent 分类、Agent 起草回复、转入审批队列。两者的协同体现在：客服反馈中的高频问题可以沉淀为 FAQ 进入知识库（knowledge_documents），反哺后续的营销内容生成。

能力四：双线账本的一致性与可审计性

平台真实账本与项目虚拟账本必须保持恒等式：project_budgets.used_amount ≡ Σ settled token_billing_reports.cost（容差 0.01）。D3 的实测发现跨侧差额 ¥0.0984，经分解 100% 归因为上报器批内 log_ref 去重挤掉的 18 行（ISSUE-W4-36），且平台侧 used_amount 与 Σ settled 的漂移（¥0.0858）归因于 numeric(*,2) 逐批累加舍入（ISSUE-W4-29）。这两个问题虽然不影响业务逻辑，但暴露了资金计量准确性的隐患，需要通过修复后的一次性重放或主控明文接受为已实现漏账来解决。

三、预置条件与环境配置

3.1 三端服务基线

端	地址	说明
PostgreSQL 17	localhost:5432	双库：ai_native_engine（平台）/ project_server（实例）
platform 后端	http://localhost:18000	公司/项目/实例/平台真实账本/计费结算/超管后台
project-server	http://localhost:8090	AI 执行引擎，当前实例绑定宿主项目 34
前端（platform-web）	http://localhost:5176	vite dev 模式，Playwright 测试入口

3.2 账号与公司设定

测试主账号：采用 lts_ 前缀，如 lts_c3_1790167890560_3851@test.com，密码统一为 test123。该账号通过注册页真实注册，非 SQL 直插。

公司设定：公司名 LTS-C3 AI营销SaaS（公司 ID 904），项目名 lts_c3_copyforge（项目 ID 1045），运行模式 full_auto（全自动），owner 为 u2271。

3.3 连接器配置

Email 连接器：用于客服邮件外发，权限设为 write_review（所有外发需人工审批），notify_to 指向测试收件箱 hayoou_com@126.com。

飞书审批通道：用于审批推送与通知链路，验证 FIX-001 的真实化效果。连接器权限同样为 write_review。

Stripe 支付连接器：由于 FIX 未做，订阅事件全部通过 harness/ingest-event.mjs 模拟注入，不进真实支付通道。

3.4 数据构建路径

公司→项目→预算基线：全部走 UI 真实路径。登录 → 创建公司 → 新建项目（三步向导：全自动 / ¥6,000 / ¥1,200）→ 引导流贴业务背景 → 组织建造（1 人 + 2 AI）→ autoops 配置起首任务组。

角色/组织起点：通过平台引导流（guided）+ PS POST /projects/:id/org/* 接口创建。扩编一律走产品 org/advice→accept，不 SQL 直插角色（否则测不到 evo 链路）。

基线快照：每场景开测时拍摄 harness/snapshots/，包含 psql 关键表行数 + 服务健康状态，所有计数断言取相对基线增量。

四、T1 生存期操作指引

4.1 UI 路径：从登录到首轮循环

1登录与全局面板

访问 http://localhost:5176/login，输入 lts_c3_* 账号密码，点击登录。进入 /dashboard 全局面板，可自定义展示模块（如项目列表、预算概览、最近轮次等）。

2创建公司与项目

点击「创建公司」，填写公司名称 LTS-C3 内容工坊，完成创建。进入公司后，点击「新建项目」，进入三步向导：

• 步骤一：选择运行模式 full_auto（全自动）
• 步骤二：设置总预算 ¥6,000、AI 运行预算 ¥1,200（D3 后改为 ¥40）
• 步骤三：填写项目描述「月费 $19/$49 的 AI 营销内容生成工具，输入品牌调性自动生成博客/邮件/推文」

提交后，项目 ID 1045 创建，状态从 draft 转为 running。

3实例绑定与执行域自检

进入项目详情页，点击「录入服务器」，填写 127.0.0.1:8090（本机测试形态）。点击「确认部署完成」，系统执行域自检：

• execution_plane_reachable=true
• hmac_verified=true（latency 1ms）
• execution_plane_selfcheck=success

自检通过后，instance_project_grants 表落库 1 行（source='push'），PS 侧 project_config 惰性建行。

4引导流与策略确认

进入 /project/1045/autoops 自动运营控制台，系统提示「策略未确认，请先完成引导建项并确认执行策略」。通过引导流 4 步走完（业务介绍→组织→定义→启动），策略确认后 strategy_confirmed=true，引擎开始自动起轮。（2026-10-07 注：这道闸即 V3 战役登记的存量项目启动闸——升级前创建、缺项目作用域确认记录的项目会被拦，重走本步骤即解锁；迁移回填方案待裁，见 wiki/testing/v3/todo.md V3-07。新建项目走完引导确认不受影响。）

5观察首轮循环

引擎启动后，auto_ops_rounds 表开始入库轮次记录。轮间隔约 60-67 秒，分引擎类型：

• agent/task：进程内 LLM + ToolCall，avg 1-2s，成本 ¥0.0046/轮
• loop/task：qianshou 子进程，avg 98-1042s，成本 ¥0.78-1.23/轮（真值样本仅 2 轮）
• review：验收轮，avg 280s，成本 ¥0.0018/轮

4.2 事件注入：订阅与客服闭环

通过 harness/ingest-event.mjs 脚本注入外部事件，模拟真实业务流。事件统一落 POST /api/v1/events，HMAC 三头签名。

事件一：试用开始

node ingest-event.mjs \
  --project 1045 \
  --scenario lts_c3 \
  --type subscription.trial_started \
  --title "trial lts-c3-001" \
  --content '{"plan":"pro-monthly","email":"t1@example.com"}'

期望反应：EventAgent 分类为 strategy_tag=revenue，status=processing，project_ledger 落分录。由于 FIX-004 未完全接通，自动开通任务可能不触发，需人工观察 event_assignments 表。

事件二：首笔订阅

node ingest-event.mjs \
  --project 1045 \
  --scenario lts_c3 \
  --type checkout.completed \
  --title "首笔订阅 $19" \
  --content '{"plan":"basic-monthly","amount":19.00}' \
  --priority important

期望反应：入账 project_ledger，自动建催缴任务（若 FIX-004 生效）。

事件三：支付失败

node ingest-event.mjs \
  --project 1045 \
  --scenario lts_c3 \
  --type invoice.payment_failed \
  --title "催缴" \
  --content '{"customer":"t1","retry_in":"3d"}' \
  --priority important

期望反应：自动建催缴任务，客服 Agent 起草催缴邮件转 pending_review。

事件四：客户支持邮件

node ingest-event.mjs \
  --project 1045 \
  --scenario lts_c3 \
  --type customer.support \
  --title "退款请求" \
  --content '{"type":"refund","reason":"unused"}' \
  --priority important

期望反应：EventAgent 分类为 strategy_tag=customer_relations，客服 Agent 起草退款处理回复，转 connector_audit_logs 的 pending_review 队列。人工在 /autoops/human 页面审批，核验收件人在白名单、含 GDPR 退订链接、无 spam 触发词。

4.3 批准外发：合规性检查

所有外发动作（邮件/发帖/支付操作）必须经过人工审批。审批入口：

• /autoops/human：人工节点审批（RACI 流程）
• /connectors/audit：连接器写动作审批（pending_review 队列）
• /autoops/acceptance-records：验收记录审批

审批要点：

• GDPR 退订链接：所有营销邮件必须包含退订链接
• 无 spam 触发词：避免「免费」「保证」「立即」等触发词
• 收件人白名单：只发给已授权的用户
• 署名规范：不提及 AI 身份，署名 ZY Pan

T1 阶段需批准 6 封外发邮件 + 1 次上线 + 1 次退款 $19，全部在 connector_audit_logs 留痕。

4.4 核心演练：预算 80% 预警 → 追加 → 恢复 → 断言队列不丢

步骤一：下压预算至触发预警

进入 /project/1045/autoops 控制台，点击「设置预算」按钮，在对话框中：

• 将「AI 运行预算」从 ¥40 改为 ¥4.96（= 当时已用 ¥4.70 + ¥0.25 余量）
• 「预警线」显式回填 80%（防默认漂移）
• 「项目总预算」回填 ¥6,000（不动总盘）
• 点击「保存」

系统发出 PUT /api/v1/projects/1045/autoops/config，HTTP 200 / code=0。PS 侧 project_config 落库 ai_budget=4.96。

步骤二：观察预警触发

由于 80% 预警线（¥3.968）已低于当前已用额（¥4.70），下一个轮次边界（约 45 秒后）PreRoundCheck 算出 pct = 4.7020/4.96 = 94.8% ≥ 80%，触发：

• budget_states.warned 从 false 翻转为 true
• 新增通知 notifications id=59，user_id=2271、project_id=1045、type=budget_alert、title=AI 运行预算预警、priority=important
• 控制台页顶栏铃铛可见预警通知
• 控制台预算卡片显示「预警」标签

步骤三：等待熔断触发

继续观察，约 40 分钟 / 64 轮后（实测 ¥0.0033/轮），ai_used 爬升至 ¥4.9606，触发 100% 熔断线：

• budget_states.ai_meltdown=true
• budget_states.meltdown=true（聚合闸）
• budget_states.total_meltdown=false（两线独立，AI 线熔断未误伤总盘线）
• budget_states.paused_at=2026-09-24 14:17:26（首次熔断时间戳）
• project_config.status=paused（引擎侧回写）
• 新增通知 id=60，title=AI 运行预算耗尽，priority=urgent
• 控制台显示「已暂停（预算熔断）」+「已超预算」红标
• 暂停后 180 秒内零新轮（停表验证）

步骤四：UI 追加预算并恢复

在控制台「设置预算」对话框中：

• 将「AI 运行预算」填回 ¥40（故事卡稳态值）
• 点击「保存」，系统调用 RecoverAfterTopUp，清除 ai_meltdown/meltdown/warned，但保留 paused_at（仅作暂停时间可观测字段），status 仍为 paused
• 点击「恢复」按钮，系统发出 POST /autoops/resume，过三道闸（run_mode 非人工复核、BudgetExceeded 已不成立、GateStatus 总盘未超），调用 ResumeProject 清 guard 旗标 + 唤醒 resumeCh
• project_config.status 转为 active，控制台文案回到「运行中」

步骤五：断言队列不丢、断点续跑

恢复后观察 auto_ops_rounds 表：

• round_no 从 592 连续到 593（无跳号、无重跑历史轮）
• 593 落库时刻距「恢复」点击 ≤2 秒（暂停期间 park 在 resumeCh 的循环被原地唤醒）
• 恢复后节奏回到 ≈60-65 秒/轮
• auto_ops_tasks 的 pending/running 队列与熔断前一致（RecoverAfterTopUp 按两线各自复核）

步骤六：稳态收口

确认以下状态：

• ai_budget=40.00（已复位，未留在低位）
• warned/degrade_mode/ai_meltdown/meltdown/total_meltdown/terminated 全 false
• 轮次持续产出（如 150 秒内 +3 轮）
• ai_used 继续增长（如 4.9912），下一次预警要到 80%×¥40=¥32 才再触发

五、T2 扩张期操作指引

5.1 A/B 测试常态化

T2 阶段的核心是验证系统能否通过 A/B 测试持续优化营销内容。每周注入一组 A/B 结果事件：

node ingest-event.mjs \
  --project 1045 \
  --scenario lts_c3 \
  --type marketing.ab_result \
  --title "A/B 测试：落地页标题" \
  --content '{"variant_a":"Increase Your Productivity with AI","variant_b":"Save 10 Hours/Week with AI Content","winner":"b","conversion_a":0.021,"conversion_b":0.034}' \
  --priority normal

期望反应：

• EventAgent 分类为 strategy_tag=marketing
• 胜出方案（variant_b）自动进入 marketing_contents 模板库，留版本链
• 驱动下一轮 review 重排优先级（优先使用胜出模板）

断言要点：

• marketing_contents 表新增行，version 字段递增
• auto_ops_rounds 中 review 轮的任务优先级调整
• 后续生成的营销内容引用胜出模板

5.2 团队扩编

随着业务增长，系统通过 POST /org/stage/sense 感知负载，GET /org/advice 产出扩编建议（含成本增量与预估回收期）。UI 面板显示「采纳并扩编」按钮，批准客服/增长/数据 3 岗。

断言要点（FIX-004 复测点）：

• 新角色 3 轮内出现在 auto_ops_rounds 绑定与 token_billing_records.role_id
• agents 表新增行，org_charts 关系更新
• growth_advice 表记录 status=applied

5.3 降价实验（黄通道）

注入降价实验事件：

node ingest-event.mjs \
  --project 1045 \
  --scenario lts_c3 \
  --type pricing.experiment \
  --title "降价实验：$19→$15" \
  --content '{"old_price":19,"new_price":15,"duration":"1w","hypothesis":"lower price increases conversion"}' \
  --priority important

降价属于黄通道动作，需人工在 /autoops/human 审批。审批要点：

• 成本增量测算：降价后需多少新增用户才能维持 MRR
• 风险评估：是否影响品牌形象
• 退出机制：实验失败如何恢复原价

5.4 SLA 超时升级

模拟客服响应超时：

node ingest-event.mjs \
  --project 1045 \
  --scenario lts_c3 \
  --type sla.timeout \
  --title "客服响应超时" \
  --content '{"ticket_id":"T-001","sla_hours":2,"actual_hours":3}' \
  --priority urgent

期望反应：human_task_nodes.escalation_level 从 0 升到 1，升级链触发，通知管理者。断言 SLASweep 扫描到该节点并调用 notifyEscalation。

六、T3 规模化期操作指引

6.1 动态预算调度

T3 阶段验证系统能否按 LTV（客户终身价值）动态分配各岗预算。通过 PUT /ledger/budget 批准弹性模式：

curl -X PUT http://localhost:18000/api/v1/projects/1045/ledger/budget \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "mode": "flexible",
    "allocation": {
      "marketing": 0.4,
      "customer_service": 0.3,
      "product": 0.2,
      "finance": 0.1
    }
  }'

断言要点：

• budget_states 表记录岗位级预算分配
• change_logs 表留痕预算调整动作
• 后续轮次的 token_billing_records 按岗位聚合，验证是否超分配

6.2 Churn 潮归因

注入批量 churn 事件：

for i in {1..8}; do
  node ingest-event.mjs \
    --project 1045 \
    --scenario lts_c3 \
    --type subscription.cancelled \
    --title "客户流失 #$i" \
    --content "{\"customer\":\"c$i\",\"reason\":\"too expensive\",\"mrr_lost\":19}" \
    --priority important
done

期望反应：

• 系统生成 churn 归因报告（decision_traces 表）
• review 轮重排优先级（优先处理挽留任务）
• 客服 Agent 起草挽留邮件转 pending_review

断言要点：

• 月 churn 率 ≤5%（Σ cancelled / Σ active）
• 归因报告覆盖 ≥80% 的 churn 事件
• 挽留邮件包含个性化优惠（如折扣码）

6.3 并发写冲突仲裁

模拟两个 Agent 同时修改同一文件：

# Agent A 修改 landing.html
node ingest-event.mjs \
  --project 1045 \
  --scenario lts_c3 \
  --type file.conflict \
  --title "并发写冲突" \
  --content '{"file":"landing.html","agent_a":"copywriter","agent_b":"seo","change_a":"headline","change_b":"meta_tags"}' \
  --priority urgent

期望反应：arbitration_cases 表新增仲裁案例，decision_logs 留痕仲裁结论（如保留两者、或按优先级选择）。断言仲裁不互相覆盖，change_logs 记录完整的版本链。

6.4 Kill-Switch 演练

冻结所有外发动作：

curl -X POST http://localhost:18000/api/v1/connectors/email-connector/kill \
  -H "Authorization: Bearer $TOKEN"

期望反应：

• 所有 write_review 连接器暂停，新外发动作转入 pending_review 但不执行
• 只读连接器（如数据查询）不受影响
• 控制台显示「外发已冻结」状态

断言要点：

• connector_audit_logs 新增行 status=pending_review 但 executed_at=NULL
• 解冻需人工在 /connectors 页面点击「恢复」

七、验收判定表

指标	通过	观察	失败
自主率（轮次）	T1 ≥50% T2 ≥68% T3 ≥78%	T1 40-50% T2 55-68% T3 65-78%	T1 <40% T2 <55% T3 <65% 或含未批写动作
干预次数	T1 ≤14 T2 ≤10/周 T3 ≤5/周	T1 15-16（且 FIX 兜底占比>50%） T2 11-12/周 T3 6-7/周	T1 >16 T2 >12/周 T3 >7/周 或审批链断裂
Token 成本	T1 ≤¥2.0/新增试用 T2 ≤¥1.2/试用 T3 ≤¥0.8/试用	T1 ≤¥2.4 收敛中 T2 ≤¥1.5 T3 ≤¥1.0	T1 >¥2.4 T2 >¥1.5 T3 >¥1.0 或分母为 0 且无收敛趋势
熔断误停	0 次 （used<阈值却暂停）	—	≥1 次
熔断→恢复一致性	队列/预算/日志三处状态一致 断点续跑 round_no 连续	仅队列一致 或 round_no 跳号但有解释	队列丢失 或预算不平 或无法恢复
AI 成本占 MRR	T2 <12% T3 <6%	T2 12-15% T3 6-8%	T2 ≥15% T3 ≥8%
外发合规	所有外发逐条批准留痕 GDPR 退订/无 spam 触发词	通知延迟（FIX-001 未验通） 但无未批外发	出现 1 笔未批外发 或含 GDPR 违规
轮次时长	loop P95 ≤90min agent P50 ≤8min	单轮>2h 一次	连续 2 轮空转/死循环

八、取证口径

8.1 三重取证体系

每场景每阶段的关键断言必须跨层交叉（单层不定论）：

L1 页面取证：Playwright 真实路径 + 全页截图入 harness/snapshots/。断言对象：面板数字、状态 tag、审批弹窗内容与按钮态、铃铛通知可见性。

L2 网络取证：请求 URL/状态码 + 业务字段 code==0 + 响应关键字段（防 200 伪成功）。通过 Playwright 的 captureApiResponse 机制捕获。

L3 psql 取证：只读查询双库表，验证落盘行存在性与字段字面量。所有 psql 命令通过 harness/lib.mjs 的 psql() 函数执行，非 SELECT/WITH 一律抛错。

8.2 关键接口与表

预算状态接口：

GET /api/v1/projects/1045/autoops/budget/state
# 返回：ai_budget, ai_used, warn_percent, warned, meltdown, total_meltdown

预算告警表：

-- AI 线告警（写 notifications 表）
SELECT * FROM project_server.notifications 
WHERE project_id='1045' AND type='budget_alert' 
ORDER BY created_at DESC LIMIT 10;

-- 总预算线告警（写 budget_alerts 表）
SELECT * FROM project_server.budget_alerts 
WHERE project_id='1045' 
ORDER BY created_at DESC LIMIT 10;

双线账本恒等式：

-- 平台侧（ai_native_engine 库）
SELECT used_amount, total_budget 
FROM project_budgets 
WHERE project_id=1045;

-- PS 侧（project_server 库）
SELECT sum(cost) as ps_total 
FROM token_billing_records 
WHERE project_id='1045';

-- 恒等式：used_amount ≡ Σ settled token_billing_reports.cost（容差 0.01）
SELECT sum(cost) as platform_settled 
FROM token_billing_reports 
WHERE project_id='1045' AND status='settled';

轮次与任务队列：

-- 熔断前后任务队列一致性
SELECT status, count(*) 
FROM auto_ops_tasks 
WHERE project_id='1045' 
GROUP BY status;

-- 断点续跑 round_no 连续性
SELECT round_no, id, created_at 
FROM auto_ops_rounds 
WHERE project_id='1045' 
ORDER BY id DESC LIMIT 10;

审批队列：

-- 连接器写动作审批
SELECT status, count(*) 
FROM connector_audit_logs 
WHERE direction='write' AND project_id='1045' 
GROUP BY status;

-- 人工节点审批
SELECT status, count(*) 
FROM human_task_nodes 
WHERE project_id='1045' 
GROUP BY status;

九、附录：环境信息

9.1 端口映射

服务	端口	说明
PostgreSQL 17	5432	双库：ai_native_engine / project_server
platform 后端	18000	公司/项目/实例/平台真实账本
project-server	8090	AI 执行引擎
前端（vite dev）	5176	platform-web 开发服务器
外网代理	7890	127.0.0.1:7890（新加坡 IP）

9.2 关键表清单

project_server 库

• events / event_assignments：注入事件与派单
• notifications：站内通知（AI 线告警写此表）
• human_task_nodes：RACI 人工节点
• approval_requests + compliance_logs + offline_tasks：flow 审批/合规
• connector_audit_logs：连接器写动作审批（pending_review 队列）
• auto_ops_tasks / auto_ops_rounds / auto_ops_schedules / auto_ops_progress：轮次调度
• acceptance_records：三权验收记录
• token_billing_records：PS 侧 token 计量
• budget_states / budget_alerts / project_config：预算控制（AI 线状态/总预算线告警/项目配置）
• project_ledger：项目虚拟账本
• amoeba_daily_stats：岗位级阿米巴核算
• agents / org_charts / growth_advice / role_versions / change_logs：组织与扩编
• decision_traces + decision_logs / arbitration_cases：决策与仲裁
• marketing_campaigns / marketing_contents：营销活动与内容版本
• knowledge_documents / knowledge_chunks：知识库

ai_native_engine 库（platform）

• companies / members / projects：公司与项目
• project_budgets：项目预算（平台侧）
• instances / provision_logs：实例管理
• platform_balances / platform_transactions：平台真实账本
• token_billing_reports：计费结算报告（status=settled）
• balance_alert_records：余额告警

9.3 Harness 脚本用法

事件注入：

cd wiki/long_term_testing/harness

# 注入订阅事件
node ingest-event.mjs \
  --project 1045 \
  --scenario lts_c3 \
  --type checkout.completed \
  --title "首笔订阅 $19" \
  --content '{"plan":"basic-monthly","amount":19.00}' \
  --priority important

# 注入客服邮件
node ingest-event.mjs \
  --project 1045 \
  --scenario lts_c3 \
  --type customer.support \
  --title "退款请求" \
  --content '{"type":"refund","reason":"unused"}' \
  --priority important

# 幂等重放（续跑）
node ingest-event.mjs --replay-pending

观察轮次：

# 只读采集 + 快照 + 台账（零副作用）
node drive.mjs

# 触发 review 轮
node drive.mjs --mode review --wait 240

# 触发 AI 分析（真实 LLM 计费，谨慎）
node drive.mjs --mode analyze --analyze-type analysis

审批模拟：

# 按规则自动审批
node approve.mjs

# 只出判定，零副作用
node approve.mjs --dry-run

# 指定队列
node approve.mjs --scope human --include-offline

# 端到端自证
node approve.mjs --selftest

台账与续跑：

# 查看台账尾部
node -e "import('./lib.mjs').then(m=>console.log(m.opsTail(20).join('\n')))"

# 健康探测
node lib.mjs

# 状态机读续跑锚点
cat ledger/state.json

9.4 数据足迹与纪律

只动 lts 前缀资产：所有测试数据采用 lts_c3_ 前缀，零触碰 project 34 / company 38 / w*_ 并发主控数据。

不 SQL 直改：所有写动作走产品 UI/HTTP 面，psql 只发 SELECT。

不 commit：产物留在工作区，由主控统一提交。

不重启服务：除非主控授权的重启窗，否则不停/未重启/未替换任何服务或 exe。

诚实分母：因 FIX 未生效而人工兜底的动作计入干预数但单列标注，不假装自主；被排除项写明不进判定分母。

文档版本：v1.1 | 更新日期：2026-10-07（同步 V3-06 预算读面实时化、V3-07 策略确认闸注记）| 依据锚点：2d4aa14